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PREFACE 


This  report  provides  Federal  computer  personnel  with 
information  about  Data  Dictionary  Systems,  their  use  and 
benefits,  and  initial  planning  for  a Federal  standard  in 
order  to  solicit  technical  discussions  and  input  from 
Federal  personnel  and  system  producers  regarding  appropriate 
content  for  a Federal  standard.  Comments  and  suggestions 
should  be  addressed  to  me  at  the  address  below.  The  conclu- 
sions or  assertions  in  this  report  are  subject  to  change. 
In  particular,  objectives  and  schedules  are  dependent  on 
funds  not  yet  appropriated.  The  contributions  of  Belkis 
Leong-Hong,  John  Berg,  and  Patricia  Konig  to  this  report  are 
appreciated . 


Dennis  W.  Fife,  Chief 
Application  Systems  Division 
National  Bureau  of  Standards 
Washington,  D.  C.  20234 
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PROSPECTUS  FOR 

DATA  DICTIONARY  SYSTEM  STANDARD 
Application  Systems  Division 


A Data  Dictionary  System  is  an  automated  in- 
formation system  to  assist  in  organization-wide 
data  management,  without  restriction  to  computer 
data.  This  report  describes  NBS  efforts  to 
develop  a Federal  Data  Dictionary  System  standard. 
It  discusses  the  scope  and  purpose  of  the  stan- 
dard, its  intended  uses,  general  issues  being  in- 
vestigated, and  the  basic  project  approach. 


Key  words:  Computer  program;  data  dictionary 
system;  data  inventory;  data  management;  data 
standards;  database;  database  management  system; 
documentation;  software. 


1.  PURPOSE  OF  THIS  REPORT 

A Data  Dictionary  System  (DDS)  is  a computer  software 
system  that  provides  for  recording,  storing,  and  processing 
information  about  data  and  its  usage.  Numerous  commercial 
and  user-developed  DDS  packages  are  available  and  increas- 
ingly are  being  used  [1,2,3].  The  National  Bureau  of  Stan- 
dards has  initiated  a project  to  develop  a Federal  standard 
Data  Dictionary  System.  This  report  explains  the  purpose  and 
various  functions  of  a DDS,  its  envisioned  benefits,  and  the 
approach  for  creating  a proposed  standard.  The  report  is 
primarily  intended  to  initiate  discussions  with  Federal 
users  about  detailed  requirements  and  with  potential  vendors 
about  implementing  the  standard  software. 


2.  DATA  DICTIONARY  SYSTEM 

The  Federal  government,  like  all  large  organizations, 
collects  a large  quantity  of  data  for  its  operations  and  de- 
cision making.  Data  collection  and  handling  are  expensive, 
and  poor  quality  can  Impede  government  services  and  decision 
making.  For  example,  problems  exist  when: 
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* data  is  collected  redundantly  by  different  depart- 
ments, or  data  is  collected  anew  instead  of  finding 
and  using  equivalent  existing  data; 

* data  is  collected  or  recorded  inconsistently;  for 
example,  different  measuring  units  or  codes  are  ap- 
plied when  similar  data  is  collected  by  two  dif- 
ferent groups . 

The  Data  Dictionary  System  (DDS),  when  consistently  and  con- 
scientiously used  by  data  management  and  computing  person- 
nel, will  reduce  problems  such  as  the  above. 


2.1  General  Functions  of  the  DDS 

The  DDS  is  itself  an  information  system  about  all  of  an 
organization's  significant  data  and  data  processing  enti- 
ties. Pertinent  entities  Include  individual  data  items  or 
elements  (such  as  client  name  or  parts  on  hand),  data  groups 
(such  as  client's  dependents),  data  collection  forms, 
records,  files,  databases,  programs,  systems,  reports,  user 
procedures,  and  users.  The  content  of  the  DDS,  often  called 
"metadata"  but  usually  called  simply  the  "data  dictionary", 
consists  of  formal  descriptions  of  the  pertinent  entities. 
An  individual  DDS  entry,  hereafter  called  an  entity  descrip- 
tion, therefore  contains  important  information  about  a named 
entity  (for  example,  the  data  element  CLIENT-NAME),  but  does 
not  contain  actual  instances  of  the  entity  (that  is,  all  ex- 
isting client  names).  Rather,  the  actual  instances  exist 
outside  of  the  DDS;  as  examples,  they  are  data  values  stored 
in  a database  or  on  a magnetic  tape  located  in  a vault. 

A DDS  may  be  used  effectively  to  describe  data  elements 
and  other  entities  that  do  not  involve  computer  processing, 
as  well  as  to  describe  computer  applications.  A fully 
developed  data  dictionary  for  an  organization  or  project  is 
a catalog  of  its  data  resources,  but  also  is  a computer  da- 
tabase that  fully  documents  its  data  collection,  processing, 
handling,  and  dissemination  activities.  A DDS  is  therefore 
an  automated  documentation  and  information  retrieval  system 
to  support  organization-wide  data  management,  without  limi- 
tation to  computer  data.  A DDS  may  have  more  substantial 
capabilities  as  an  active  component  of  computer  applica- 
tions, as  will  be  described  later  in  this  section. 

The  term  "data  dictionary",  which  stems  from  the  early 
applications  that  simply  catalogued  and  defined  data  ele- 
ments, is  no  longer  completely  appropriate  and  descriptive, 
but  nevertheless  continues  to  be  widely  used  and  will  be  re- 
tained in  the  Federal  standard  effort  until  a better  term  is 
evident . 
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To  summarize,  a DDS  provides  capability  for: 

1.  Specifying  the  type  of  an  entity,  such  as  a form,  a 
data  element,  or  a computer  file. 

2.  Uniquely  naming  an  entity  and  describing  it  in  ap- 
propriate terms,  such  as  the  range  of  values  of  a 
data  element  or  a narrative  description  of  its  mean- 
ing . 

3.  Specifying  the  flow  and  the  storage  locations  of 
data  within  the  organization  or  within  the  computer 
installation . 

4.  Specifying  associations  and  relationships  among  the 
data  entities;  for  example,  appearance  on  the  same 
form,  or  derivation  of  one  entity  from  another. 

5.  Specifying  and  producing  reports  about  the  data  dic- 
tionary content,  such  as  a listing  of  all  data  ele- 
ments or  a cross-reference  listing  of  all  entitles. 

2.2  Types  of  Entity  Descriptions 

A DDS  provides  a prescribed  set  of  different  entity 
types;  each  type  has  a prescribed  set  of  attributes.  These 
attributes  describe  an  entity  of  the  given  type.  An  entity 
description  is  entered  into  the  data  dictionary  through  the 
DDS  as  one  or  more  text  lines  that  name  the  entity  and  its 
type,  and  give  values  for  the  applicable  attributes.  The 
entity  name,  type  designation,  and  other  attributes  must 
follow  the  prescribed  conventions  of  the  DDS.  For  example, 
an  entity  name  may  be  from  one  to  30  alphanumeric  characters 
only;  the  type  designation  must  be  one  of  the  established 
codes,  such  as  EL  for  data  element  or  SD  for  source  docu- 
ment. For  some  entity  types,  an  available  attribute  may  be 
a text  field,  say  up  to  150  characters,  for  entering  a nar- 
rative description  pertinent  to  each  entity. 

Figures  lA  and  IB  present  two  examples  of  actual  entity 
descriptions,  coded  in  the  language  of  two  different  commer- 
cial DOS's,  DATAMANAGER  and  DATA  DICTIONARY.  Figure  2 is  a 
very  brief  summary  to  illustrate  available  DOS's,  see 
[1,2,3]  for  more  information. 
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FIGURE  lA 


Example  of  a Data  Element  Entity  Description 
(Coded  Using  DATAMANAGER) 


ADD  CUSTOMER-NUMBER 
ITEM 

ENTERED-AS  CHAR  7 

CONTENTS  FORMAT  "ANNNNNN” 

HELD-AS  ALPHANUMERIC 

REPORTED-AS  PICTURE  'A9(6)' 

DESCRIPTION 

'CUSTOMER  NUMBER  UNIQUELY  IDENTIFIES  A CUSTOMER  ACCOUNT' 
CATALOGUE 

'SALES',  'BILLINGS',  ' ACCOUNTS-RECEI VABLE ' 

ALIAS  ASSEMBLER  'CUSNO' 

NOTE 

'NUMBER  ORIGINATES  IN  SALES  DEPARTMENT' 

'SOURCE  DOCUMENT  NUMBER  IS  FM2152' 

'USED  BY  SALES,  BILLINGS,  ACCOUNTS  RECEIVABLE  SYSTEMS' 
'USED  AS  KEY  IN  THE  CUSTOMER  NAME  AND  ADDRESS  FILE' 


FIGURE  IB 

Example  of  a Source  Document  Entity  Description 
(Coded  Using  CINCOM's  DATA  DICTIONARY) 


SF-171  SD  ADD  NAME=AP-FORM  DESC*'APPLIC  FORM  FOR  FED  EMPL', 
ELEMENT=APPL-SYS , FED-REG-SYS,  APPLICANT-REC , 
USER=PERSONNEL 
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FIGURE  2 


A Sample  of  Currently  Available  Systems 


DDS 

CONTACT  NAME 
AND  ADDRESS 

HARDWARE 

i MAIN 
1 MEMORY 

1 COST 

1 (*)=GSA  Sche 

1 

1 

DATA  CATALOGUE 

IBM  360/370 

1 100-125K 

1 $12. 9K-37K(*) 

Synergetics  Corp 

1 

1 De  Angelo  Dr . 

1 

Bedford,  MA  01730 

UNIVAC-llOO 

1 25-35K 

1 $21 . 9K-33K(*) 

617-275-0250 

1 

1 

DARCOM 

IBM  360/65 

1 150K 

1 Negotiated 

US  Army  Materiel 

1 

Development  & 

1 

Readiness  Cmd. 

1 

Cmd'r.  Autom.  Logistid 

1 

Mgt»  Activities 

1 

Attn.  DRXAL-DED 

1 

P.O.  Box  1578 

1 

St.  Louis,  MO 

1 

314-268-6001 

1 

__  1 

IDD 

IBM  360/370 

1 IDMS  DB 

1 $15K(*) 

CULLINANE  CORP 

IBM  4330/4340 

1 

20  William  St. 

IBM  303x 

1 stand-alone 

: 1 

Wellesley,  MA  02181 

1 350K  vlrtuall 

617-237-6600 

1 

__  1 

PRIDE/Logik 

IBM  360/370 

i 12  8K 

1 

M.  Bryce  & Assoc 

1 $27K 

1248  Springfield  Pk 

DEC-10, DEC-20 | 

1 

Cincinnati,  OH  45215 

B-3700, 4800 

1 

513-761-8400 

H6000 

1 

ICL-1903 

1 

CDC-CYBER 

1 

__  1 

RAS/ STADES 

H 6000 

i 29K 

1 Negotiated 

US  Navy  Data  Autom. 

IBM  360/370 

1 

Cmd.  (NAVDAC) 

1 

NARDAC 

UNIVAC-llOO 

1 

Bldg.  196 

1 

Washington  Navy  Yard 

1 

Washington  DC  20374 

1 

202-433-3571 

— 

1 

— 1 
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A DDS  could  also  provide  for  the  user  to  define  addi- 
tional types  of  entities  and  their  attributes,  and  then  sub- 
sequently to  enter  entity  descriptions  according  to  these 
user  defined  types. 

The  conventions  and  attributes  of  data  entity  descrip- 
tions are  especially  important  in  assessing  a DDS.  Data 
descriptions  are  essential  to  almost  all  computer  programs. 
For  example,  a COBOL  application  program  requires  a DATA 
DIVISION.  A database  management  system  (DBMS)  requires  a 
description  of  its  database  using  its  Data  Definition 
Language  (DDL).  Central  storage  of  data  descriptions  under 
a DDS  can  improve  data  standardization,  integrity,  and  con- 
trol considerably,  if  the  DDS  can  compile  and  output  select- 
ed descriptions  with  the  form  and  content  required  by  other 
software.  Many  DDS  packages  are  specifically  designed  for 
this  purpose,  so  their  data  descriptions  do  incorporate  the 
necessary  information  at  least  for  one  software  system  such 
as  a given  DBMS  or  for  a category  of  software  such  as  COBOL 
programs.  However,  the  syntax  of  the  DDS  language  usually 
differs  substantially  from  that  of  the  DBMS  DDL  or  the  COBOL 
DATA  DIVISION. 

2.3  Types  of  DDS 


There  are  two  principal  ways  to  classify  the  wide  range 
of  capabilities  and  implementations  found  in  present  DDS. 
One  way  is  according  to  the  DDS  capability  to  provide  data 
entity  descriptions  to  other  software.  In  this  respect,  the 
DDS  could  be  called  passive  or  active.  Another  classifica- 
tion is  according  to  the  dependence  of  the  DDS  on  other 
software  for  implementing  its  functions.  Here  it  could  be  a 
stand-alone  DDS  or  a dependent  one. 

2.3.1  Passive  and  Active  DDS.  A passive  DDS  is  an  informa- 
tion tool  that  is  only  accessed  by  personnel,  to  enter  or 
retrieve  entity  descriptions.  With  a passive  DDS,  descrip- 
tions of  the  same  data  will  exist  concurrently  in  other 
software  such  as  COBOL  programs.  Changes  in  the  DDS  content 
do  not  automatically  produce  corresponding  changes  in  the 
other  data  descriptions,  and  vice  versa.  Thus  a passive  DDS 
does  not  control  the  organization's  data  descriptions 
directly,  although  it  would  assist  manual  procedures  to  do 
so  . 


An  active  DDS,  through  software  interfaces  and  computer 
operating  procedures,  provides  the  ONLY  source  for  data 
descriptions  to  other  processing  components  such  as  com- 
pilers, assemblers,  and  DBMS's.  The  active  DDS  assists  in 
the  enforcement  of  data  standards  and  usage  throughout  the 
organization  and  its  computer  applications.  For  example,  an 
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active  DDS  could  produce  the  DATA  DIVISION  for  any  COBOL 
program  from  dictionary  data  and  parameters  supplied  in  the 
job  stream.  The  text  would  be  collated  with  the  program 
source  text  and  passed  to  the  COBOL  compiler.  Here  the  DDS 
is  said  to  be  active  with  respect  to  the  COBOL  compiler. 

2.3.2  Stand-alone  and  Dependent  DDS.  A stand-alone  DDS  is 
self-contained;  that  is,  its  functions  are  performed  without 
relying  on  any  other  general  purpose  software  such  as  a 
DBMS.  A stand-alone  DDS  may  be  passive  or  active.  Most  of 
the  current  stand-alone  implementations  have  available  the 
features  that  make  them  active  when  invoked  by  a user. 

A dependent  DDS  is  specifically  tailored  to  operate  in 
conjunction  with  another  general  purpose  software  system, 
usually  a DBMS.  It  requires  the  DBMS  facilities  to  perform 
DDS  functions.  In  some  cases,  the  dependent  DDS  is  imple- 
mented as  an  application  under  a DBMS,  wholly  using  DBMS  fa- 
cilities. Such  an  intimate  connection  does  not  necessarily 
mean  that  a dependent  DDS  is  automatically  active  with 
respect  to  the  DBMS.  However,  it  may  be  easier  to  invoke  fa- 
cilities that  would  make  the  DDS  active. 


2.4  Roles  of  the  DDS 

As  the  central  repository  of  current  and  accurate  in- 
formation about  an  organization's  data  and  its  handling,  a 
DDS  can  assist  a wide  range  of  management  and  technical 
tasks.  The  following  identifies  several  application  areas 
where  use  of  a DDS  is  appropriate. 

2.4.1  Data  Resource  Management.  Because  of  the  impact  of 
government-directed  data  collection  on  the  private  sector 
and  also  the  increasing  costs  of  labor-intensive  data  han- 
dling, government  agencies  are  striving  to  reduce  redundant 
data  collection  and  to  improve  the  utility  of  existing  data 
resources.  A well-developed  DDS  provides  high  visibility  to 
similar  data  elements,  forms,  and  collection  procedures,  and 
reliably  identifies  current  holdings  [4,5].  Officials  who 
control  data  collection  projects  or  data  usage  can  use  DDS 
reports  to  eliminate  unnecessary  data  gathering  and  to 
redirect  data  management  to  reduce  costs  and  improve  overall 
effectiveness  [6,7,8]. 

2.4.2  Data  Standardization.  Data  collected  for  one  purpose 
often  cannot  serve  another  because  Inappropriate  standards 
were  used  in  the  original  collection.  NBS  is  producing 
selected  government-wide  data  standards  under  its  Data  Ele- 
ment and  Representation  Standards  program,  but  each  agency 
must  also  undertake  data  standardization  for  its  unique  con- 
cerns [9].  A DDS  can  be  used  to  record  the  data  standards 
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applied  to  every  data  element,  and  to  assist  auditing  to  as- 
sure that  the  required  standards  are  in  effect.  Moreover,  an 
active  DDS  can  be  used  as  the  source  of  established  data 
standards  when  needed  by  various  activities,  and  also  can 
participate  in  computer  processes  that  edit  and  validate 
data  against  the  established  standards. 

2.4.3  System  Development  and  Documentation.  The  DDS  is  a 
valuable  documentation  tool  over  the  entire  life  cycle  of 
systems,  procedures,  and  software  [10,11,12]. 

During  the  requirements  definition  of  new  systems,  data 
is  collected  about  data,  processes,  and  usage  requirements. 
Descriptions  of  these  requirements  can  be  stored  in  the  DDS, 
and  used  in  conjunction  with  analysis  and  design  software  to 
analyze  various  aspects  of  the  system  under  development. 
Subsequent  changes  to  the  requirements  definitions  can  be 
easily  made  and  reported  to  all  affected  offices  and  person- 
nel, thereby  minimizing  errors  due  to  inadvertent  omissions 
or  changes. 

Using  the  current  descriptions  of  the  entities  and 
their  relationships,  an  active  DDS  can  produce  data  descrip- 
tions for  individual  software  modules.  When  used  in  conjunc- 
tion with  design  aids,  the  DDS  can  produce  descriptions  of 
alternative  file  or  database  designs  for  evaluation. 

During  development,  the  DDS  can  produce  data  division 
and  documentation  for  application  programs.  It  can  also 
produce  the  actual  DATA  DIVISION  for  COBOL  programs,  or  the 
data  definition  language  (DDL)  for  the  DBMS 

During  software  testing,  the  DDS  can  help  generate  the 
test  data  by  using  the  entity  descriptions  which  already  ex- 
ist in  the  dictionary.  During  maintenance  and  modification, 
the  DDS  is  useful  in  determining  the  effect  of  proposed 
changes  on  other  entities  in  the  operational  environment. 

The  DDS  can  assist  in  producing  documentation  con- 
currently with  development,  rather  than  after  the  fact.  As 
applications  are  designed  and  programs  are  written,  the  per- 
tinent entity  descriptions,  entered  in  the  DDS,  will  elim- 
inate the  need  to  divert  manpower  later  for  documentation 
after  the  application  is  completed. 

2.4.4  Conversion . Lack  of  documentation  is  undoubtedly  the 
primary  barrier  to  economical  and  complete  conversion  of  ap- 
plications from  one  computer  system  to  another.  Poor  docu- 
mentation can  force  an  agency  to  do  a system  redesign,  and 
inappropriate  or  fragmented  documentation  can  Impede  the  use 
of  automated  conversion  aids.  Consistent  and  thorough  use 
of  a DDS  can  substantially  eliminate  documentation  problems 
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and  facilitate  conversion.  Most  importantly,  an  active  DDS 
can  provide  the  data  descriptions  necessary  to  drive  au- 
tomated file  conversion  software  [13]. 

2.5  Potential  Benefits 

Using  a DDS  provides  economic  and  technical  benefits.  A 
DDS  may  provide  immediate  savings,  or  it  may  facilitate  a 
continuing  technical  process  by  making  it  easier  or  more  re- 
liable to  perform.  To  summarize  the  benefits: 

* Better  control  of  the  organization's  data  resources 
through  improved  (i.e.,  centralized,  rigorous,  and 
standardized)  data  definitions,  data  handling  and 
data  collection. 

* Improved  transportability  of  data  and  software 
between  computing  environments  through  standardized 
data  elements  and  data  definitions. 

* Improved  documentation  for  databases,  programs,  and 
systems . 

* Automatic  compilation  of  data  definitions  to  be  in- 
cluded in  application  programs  or  in  DBMS  database 
definition. 

* Increased  security  and  access  control  for  the  data- 
base environment. 

* Effective  aid  to  software  development,  modification, 
and  maintenance  through  configuration  management  of 
system  components  of  data  and  programs. 

* Increased  cost  effective  use  of  data  resources 
throughout  the  system  development  life  cycle. 


3.  OBJECTIVES  AND  SCOPE  OF  THE  DDS  STANDARD 

The  Federal  Data  Dictionary  System  standard  will  be  a 
software  specification  which  a Federal  ADP  manager  may  use 
to  acquire  a DDS.  NBS  will  publish  the  specification  as  a 
Federal  Information  Processing  Standard,  so  that  it  may  be 
used  in  conjunction  with  Federal  Property  Management  Regula- 
tions (FPMR)  for  Federal  procurement  purposes. 
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The  objectives  of  the  Federal  DDS  standard  are: 


1.  To  define  a standard  tool  that  will  provide  better 
management  and  control  of  a using  organization's  in- 
formation resources. 

2.  To  aid  in  the  portability  of  DDS  software,  applica- 
tion software,  and  related  data. 

3.  To  facilitate  selection,  evaluation,  and  procurement 
of  DDS  software. 

Portability  assists  Federal  agencies  to  preserve  their 
investments  in  programs  and  data,  by  providing  the  ability 
to  transfer  computer  programs  and  associated  data,  including 
the  DDS  contents,  from  one  computer  system  to  another, 
without  being  required  to: 

1.  Re-create  or  re-enter  data  descriptions,  except  by 
an  unload/reload  process; 

2.  Modify  significantly  the  DDS  application  that  is  be- 
ing transported;  and 

3.  Learn  additional  user  languages  in  order  to  communi- 
cate with  another  DDS  implementation. 

The  Federal  DDS  standard  must  be  flexible  to  use  in  a 
wide  spectrum  of  applications.  This  will  be  sought  with  pro- 
gressive levels  of  sophistication  or  capability  provided  in 
the  standard  DDS.  That  is,  users  will  find  increasing  levels 
of  capability  available  as  necessary  to  meet  increasingly 
difficult  application  needs  within  their  organization. 

Guidance  will  be  provided  to  Federal  agencies  to  help 
them  determine  the  appropriate  circumstances  for  using  a 
DDS.  The  Federal  DDS  standard  will  NOT  require  agencies  to 
use  a DDS  in  all  applications.  However,  whenever  an  agency 
decides  to  implement  DDS  software  or  services,  the  Federal 
DDS  standard  specification  shall  be  used  as  the  basis  for 
procurement  action. 

A number  of  working  assumptions  characterize  the  capa- 
bilities envisioned  for  the  Federal  DDS  standard.  The 
Federal  DDS  standard  will: 

1.  Specify  a computer  software  system. 

2.  Describe  or  specify  (as  appropriate)  the  functional 
interfaces  and  data  interchanges  between  the  DDS  and 
other  software  components  (e.g.,  operating  system) 
that  users  may  need  to  operate  the  standard  DDS. 
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3.  Specify  a data  description  language  sufficient  to 
document  (for  human  users)  the  data  elements,  enti- 
ties, and  aggregates  processed  in  selected  applica- 
tion programs  and  database  management  software  pack- 
ages. 

4.  Specify  input,  output,  and  manipulation  functions 
and  associated  language  for  human  users  to  apply  and 
exploit  t he  DDS . 

5.  Provide  for  definition  of  data  element  sources  and 
users  including  forms,  computer  programs,  and  organ- 
izational units. 

6.  Provide  a flexible  facility  for  selecting  and  re- 
porting desired  information. 

7.  Specify  a stand-alone  DDS,  independent  of  specific 
vendor  hardware  or  supporting  software,  in  order  to 
enhance  the  portability  of  DDS  applications. 

8.  Specify,  as  a minimum,  a passive  DDS  capability  that 
shall  be  provided  in  its  entirety  within  a 
standard-conforming  DDS,  for  documenting  and  cata- 
loging an  organization's  data  resources. 

9.  Provide  for  additional  functional  modules  as  options 
for  Federal  requirements.  This  provides  desired 
flexibility  in  the  standard  DDS. 


4.  REQUIREMENTS  ISSUES  AND  PROJECT  APPROACH 

To  define  further  the  Federal  DDS  standard,  NBS  is  now 
conducting  a requirements  study  to  resolve  major  Issues  per- 
tinent to  the  Federal  user  community.  The  study  will  assess 
the  feasibility  of  Including  specific  DDS  functions  and 
capabilities.  To  accomplish  this,  the  project  approach  con- 
tains the  following  elements: 

1.  Close  and  continuing  interaction  with  the  Federal 
community  to  determine: 

* whether  a particular  capability  is  useful  to  the 

Federal  community; 

* whether  a sufficiently  important  segment  of 
Federal  users  has  indicated  the  need  for  a given 
capability ; 
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* whether  it  is  desirable  to  have  the  capability  in 

view  of  known  constraints;  and 

* whether  users  plan  to  incorporate  the  capability 

in  their  data  processing  operations. 

2.  In-depth  technological  assessments  and  intensive 
consultation  with  vendors,  software  suppliers,  the 
research  community,  and  Federal  developers  of  in- 
house  data  dictionary  systems,  to  determine: 

* whether  it  is  technologically  practical  to  develop 

a particular  capability  in  the  near  future,  e.  g. 

3 to  5 year  range;  and 

* if  technically  feasible,  whether  it  is  economical 

for  the  software  industry  to  produce  such  a capa- 
bility in  a competitive  market. 

3.  Formal  solicitation  of  comments  and  suggestions  from 
all  affected  communities  throughout  the  entire 
developmental  and  standardization  process. 

4.  Continuing  interchange  with  related  activities  in 
the  American  National  Standards  Institute,  and 

5.  Periodic  reports  of  current  NBS  plans. 

All  of  these  elements  indicate  the  fundamental  intent 
to  develop  a standard  DOS  that  will  be  adopted  by  Federal 
agencies  and  implemented  by  a wide  spectrum  of  suppliers. 

At  present,  NBS  staff  are  identifying,  analyzing  and 
defining  DDS  requirements  as  found  in  existing  data  diction- 
ary systems  developed  by  private  suppliers  and  Federal  agen- 
cies, as  expressed  in  literature,  and  as  expressed  during 
interviews  with  selected  agencies.  From  this  data,  NBS 
plans  to  develop  a Functional  Requirements  report  in  Fiscal 
Year  1981.  NBS  plans  various  dissemination  efforts  for  this 
report,  including  media  announcements  and  workshops.  This 
review  process,  besides  confirming  that  Federal  needs  are 
properly  represented,  will  help  NBS  to  refine  and  elaborate 
the  needed  capabilities.  Further  development  will  proceed  so 
that  official  review  of  a candidate  standard  would  take 
place  early  in  FY83.  Then  a recommended  standard  would  be 
forwarded  for  approval  by  the  Secretary  of  Commerce  before 
the  close  of  FY83. 

The  Functional  Requirements  report,  as  the  next  major 
step  of  development,  will  be  organized  along  the  lines  in- 
tended for  the  standard.  It  will  establish  initial  priori- 
ties among  the  wide  spectrum  of  possible  DDS  capabilities. 
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extending  from  and  refining  the  list  in  section  3 of  this 
document.  Commonly  provided  and  needed  facilities  will  be 
organized  into  logically  and  operationally  related  groupings 
or  modules.  More  sophisticated  and  innovative  functions 
will  be  described  also  as  additional  modules  to  provide  the 
progressive  capability  levels.  This  report  also  will  show 
initial  NBS  conclusions,  drawn  from  interviews,  from  the 
current  literature,  and  from  product  analysis,  on  several 
important  requirements  Issues: 

* Feasibility  of  a single  user  language  for  all  DDS 
f unc  t ions ; 

* Needed  entity  types  and  attributes; 

* Active  operational  modes  and  interfaces,  especially 
to  support  automated  file  conversion  and  DBMS  inter- 
faces; 

* Features  to  support  distributed  database  systems  and 
distributed  processing  systems; 

* Feasibility  of  an  effective  DDS  on  small  computers 
(minis  or  micros). 

To  summarize  the  estimated  schedule  for  the  planned  project 
events : 

* Fiscal  Year  1981  — Disseminate  Functional 

Requirements 

* Early  Fiscal  1983 — Publish  candidate  standard  in 

Federal  Register 

* Before  Close  of  — Transmit  recommended  standard 

Fiscal  1983  for  approval  by  the  Secretary  of 

Commerce . 
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